The Service Oriented Architecture (SOA) is a software architecture for implementing web applications. When using the SOA, an application is composed of a set of agents that communicate with each other using a defined set of Application Programming Interfaces (APIs) which may be described using a standard interface definition language (IDL), such as WSDL (Web Service Description Language) or some other language.
An agent that implements an interface is known as a provider or producer agent and an agent that uses an interface is known as a requester or consumer agent. An agent may be both a provider agent and requester agent.
Agents are loosely coupled together. The communication between agents occurs using the defined APIs. Two provider agents may be considered interchangeable if they implement the same set of APIs. Two requester agents may be considered interchangeable if they use the same set of APIs. An agent that is both a provider agent and requester agent may be considered interchangeable if they implement the same set of APIs and use the same set of APIs. An agent may be replaced with an interchangeable agent without requiring changes to other agents in the SOA application.
Developers of an SOA application, that may include both requester and producer agents, may develop the agents separately. The developers may update or modify the producer and requester agents independently, as long as they share a common interface. For example, a developer may update a requester agent by adding a better user interface for displaying information received from the producer agent. This new version of the requester agent can communicate with the producer agent using the same common interface as was used by the old requester agent. Likewise, the developers may update the producer agent, for example, to generate information in a more efficient manner. So long as the new version of the producer agent implements the common interface used by the previous version of the producer agent, the requester agents will be able to communicate with the new producer agent.
Although agents are loosely coupled to other agents, they are tightly coupled to the interfaces. Agents are tightly coupled to the interfaces that they use or implement, since changing an interface requires changing both the producer agent and requestor agent that implement or use the interface. The tight coupling of agents to the interfaces causes a problem for developing new SOA applications or components that may benefit from a different interface. In order to implement and use a new interface definition, both new requester agents and producer agents are required. It may be difficult to distribute all of the new components to update the old versions at the same time. This can result in an old requester agent trying to communicate with a new producer agent, or new requester agents trying to communicate with old producer agents, which will not work since they do not share a common interface.
Attempts to address this limitation have included isolating the core logic of the producer or requester agent from the interface implementation. This allows for different interfaces to be implemented using specific adaptors that compensate for differences between the interface and the core logic APIs. For example, a producer agent could be created with a new version of the core logic and an adaptor for implementing an older interface. The adaptor would be hard-coded and specific to both the new core version and the interface definition it is implementing. Another producer agent may also be created using the same core version but with a different adaptor that implements a new interface definition, for example, for supporting new features in the core version. An old requester agent can connect to the producer agent that includes the adaptor implementing the older interface. A new requester agent could connect to the producer agent that includes the adaptor implementing the new interface.
The use of adaptors for implementing an interface and adapting it to core logic provides flexibility in defining the interface, as well as the core logic, since both the interface and the core logic may change independently. However, whenever a new interface or new version of core logic is developed, a new adaptor needs to be created. Each adaptor is specific to a particular interface definition, and converts received messages into requests that can be handled by the specific core logic, as well as converting messages from the core logic into messages that conform to the particular interface definition. As the core logic evolves, this solution requires that new adaptors be created for bridging the new core logic with the different agent interfaces. This can result in having to develop numerous adaptors to support different versions of interfaces, which may be difficult as the adapter requires specific knowledge of the functions of the new core logic. Each adaptor bridges messages from one version of an interface definition to the new core logic.
Another attempt to address this limitation requires maintaining multiple cores in a single component. Each core implements a particular version of the interface. This allows for the interface definition of the agent to change significantly over time since the older interface definition remains implemented by the core. However, this causes the agent to continually increase in size and complexity, making it more difficult to maintain the agent.
A further solution to the limitation is to force the responsibility of compatibility onto system administrators. This requires systems administrators to ensure that all components in the system use the correct version. While this solution simplifies the design and authoring of the agents, it is a difficult solution for system administrators, especially as the size of the system and number of agents increase.
It is desirable to have a mechanism to provide at least some flexibility to modify interfaces or core logic of agents, while remaining simple to maintain compatibility between versions.